Julia Martin: JavaScript ist mittlerweile eine feste Größe unter den Programmiersprachen. Im Kontext von WebAssembly hört man aber auch, dass JavaScript bald auch wieder unwichtig wird. Wie kommt das, wie kann das sein?
Christian Weyer: Ich glaube, das kann gar nicht sein. Ich glaube nämlich einfach, dass das nicht stimmt. WebAssembly ist eigentlich dafür gemacht, um nativen Code auf Basis von C und C++ auf irgendeine Art und Weise in den Browser zu bekommen, ohne dass man irgendwelche Plug-ins braucht, so wie früher mit Flash, Silverlight oder Java. Ich glaube nicht, dass es – zumindest auf die nächsten Jahre, auf absehbare Zeit – JavaScript irgendwie obsolet machen wird. Ganz im Gegenteil: Die momentane Ausprägung von WebAssembly braucht sogar noch ganz viel JavaScript, weil es ein sehr einfaches Produkt ist – also ein MVP – ein Minimum Viable Product, so eine Version eins von WebAssembly. Man kann viele Dinge einfach nicht machen, ohne dass man wirklich ziemlich viel JavaScript braucht, um zum Beispiel Daten auszutauschen von dem nativen Code in den Browser und wieder zurück. Also ich glaube nicht, zumindest wie gesagt für die nächsten paar Jahre, dass JavaScript irgendwie abgelöst wird.
Julia Martin: Muss man denn mit WebAssembly nun auch keine Websprache mehr lernen, um für das Web programmieren zu können?
Christian Weyer: Das ist so die klassische Frage. Schauen wir uns kurz an, wie das Ganze heißt: Web. Assembly. Das Web ist das Web. Wir sind heute an dem Punkt angekommen mit dem Erfolg des Webs. Jeder macht es heute. Auch diejenigen, die heute immer noch native Anwendungen für Mobile machen oder native Anwendungen für den Desktop. Irgendwann kommt man dann doch auf den Draht und sagt: „Naja, ok die Webplattform ist so stark und mächtig mit Progressive Web Apps und dann zukünftig mit WebAssembly“, dass es halt schon Sinn ergibt, das als universelle Plattform anzusehen.
Deswegen: Du musst das Web verstehen. Du musst das Web kennen. Du musst HTML können. Du musst CSS können. Du musst JavaScript können. Der Erfolg des Webs ist heutzutage deswegen gegeben, weil das Web und die Webcommunity so funktionieren, wie sie funktionieren: Mit ihrer Offenheit, mit ihrer Vorgehensweise, mit ihrem Drang, das Ganze immer weiter zu treiben. Deshalb musst du eigentlich schon profund sein in deinem Wissen, wenn es um diese Technologien geht. WebAssembly ist jetzt nur noch ein neues Werkzeug im Webwerkzeugkasten.
Julia Martin: Ist WebAssembly schon bereit für die Produktion, oder gibt es da noch Einschränkungen? Was ist deine Einschätzung?
Christian Weyer: Da es momentan nur eine V1 ist, also eine allererste Inkanation der Spezifikation, und die jetzt mittlerweile doch von jedem größeren Browserhersteller implementiert wurde, ist es zwar jetzt da und man kann eigentlich schon was damit machen. Aber so richtig ernsthafte Anwendungen sind teilweise noch nicht möglich. Also A: Es fehlt das Tooling, die ganze Compiler-Toolchain für die jeweiligen Plattformen ist noch nicht wirklich fertig und ausgereift, und es fehlen grundlegende technische Dinge wie Multithreading oder wie Zugriff auf das Document Object Model, auch Garbage Collection gibt es noch nicht. Da liegt also noch einiges im Argen. Man kann einfach Dinge machen, wie zum Beispiel C++ oder C-basierte Rechenkernel oder Algorithmik, die eben keine Garbage Collection brauchen und auch nicht mehrere Threads benötigen, die dann auch nur noch einfache Datentypen austauschen müssen mit der umschließenden Webanwendung. Das kann man heutzutage schon machen. Aber das Gremium und Konsortium arbeiten an der Spezifikation der nächsten Stufe, also der Version zwei, wo dann all diese Löcher gestopft werden sollen. Aber das dauert halt noch einige Monate bis Jahre, bis wir dann auch etwas Sinnvolles sehen werden.
Julia Martin: Es geht ja auch viel um die Performance von Anwendungen im Kontext von WebAssembly. Warum gibt es diesen Unterschied und wie groß ist der eigentlich im Vergleich von WASM zu JavaScript?
Christian Weyer: Eine der Designrichtlinien bzw. -vorgaben für WebAssembly war eben, hoch performanten Bytecode ausführen zu können, der eben nicht so interpretiert und abgearbeitet werden muss, wie JavaScript innerhalb der Browser Engine. Jetzt ist es aber in der Realität so, dass der Unterschied vielleicht gar nicht so groß ist, wie man ihn haben möchte. Am Ende des Tages bleibt es aber, wie es eigentlich immer ist, bei dem Thema Performance. Dabei ist es wurscht, ob Web, Desktop oder Mobile. Du musst deinen Anwendungsfall, deinen Use Case, wirklich testen, um echte Zahlen und Werte dahinter zu haben, um dann feststellen zu können: „Ok, hier haben wir jetzt ein Problem. Könnte uns die Implementierung in WebAssembly an der Stelle weiterhelfen?“ Es ist natürlich schwierig, weil viele Anwendungen in JavaScript gebaut sind, und sie funktionieren gut, sind auch schnell genug oder eben nicht. Da jetzt aber die Argumentation aufzunehmen: „Jetzt bauen wir das Ganze mal in WebAssembly, um zu gucken, ob es schneller ist.“, das funktioniert oft gar nicht. Du hast ja dann schon so einen Invest, um nur auszuprobieren, ob das jetzt schneller wäre.
Von daher: Ja, es ist zwar auf Performance ausgelegt und getrimmt, aber in der Realität ist es wahrscheinlich relativ schwierig herauszufinden, ob jetzt das native JavaScript oder das native WebAssemby für den jeweiligen Anwendungsfall performanter wäre.
Julia Martin: Wo setzt man am besten an, wenn man WebAssembly in ein bestehendes Projekt integrieren möchte?
Christian Weyer: Das ist eigentlich der interessante Punkt. Du hast irgendwo Code in C oder in C++. Mittlerweile geht es auch mit anderen Programmiersprachen, zum Beispiel Rust oder Go. C# und .NET sind mittlerweile auch in einem experimentellen Stadium. Du hast also irgendwo Code herumliegen, zum Beispiel im Banken-, Versicherungs- oder Industrieumfeld, und möchtest diesen Code teilweise in einer Webbrowserumgebung benutzen, oder aber du möchtest eine webbasierte Anwendung bauen, die auch offlinefähig ist, weil du nicht immer Zugang zu deinem Server oder dem Internet hast. Dann kannst du WebAssembly und die Toolkits dazu verwenden, um dann exemplarisch diesen Rechenkern oder die Algorithmik zu kompilieren von C/C++ rüber nach WebAssembly, und kannst das dann in die existierende Anwendung einbauen, zum Beispiel in eine Angular-Anwendung.
In meinem Vortrag zeige ich, wie man in eine kleine existierende Angular-Anwendung, eine komponentenbasierte Anwendung, WebAssembly-Code einpflegt, der ursprünglich in C geschrieben wurde. Der eigentliche Anwendungsentwickler, der das UI drüberbaut, bekommt davon gar nichts mit, weil du innerhalb von Angular irgendwelche Architekturpatterns hast, wo du das relativ gut verstecken und einbetten kannst, sodass dann der eigentliche UI-Entwickler damit gar nichts mehr zu tun hat.
Julia Martin: Danke Christian, wir freuen uns auch schon auf deinen Workshop. Eine letzte Frage habe ich noch: Progressive Web Apps, WASM oder etwas ganz anderes. Welche Technologie wird denn deiner Meinung nach eine große Welle der Disruption im Web auslösen?
Christian Weyer: Die Mischung wird es machen. Ich glaube, wir sind bei dem ganzen Thema Clientanwendungen am Ende einer Evolutionsphase angelangt. Wir sind uns alle einig, dass das Web die mächtigste, die universellste und wahrscheinlich die Plattform ist, die im Plattformkampf mehr oder weniger gewonnen hat. Jetzt geht es nur noch um Details und Optimierungen. Wir brauchen natürlich PWA-Themen, um zum Beispiel Offlinefähigkeit hinzubekommen, damit sich die Web-Apps ein bisschen nativer anfühlen, damit wir mehr Features von der nativen Plattform bekommen, aber dennoch im Browser leben können. Wir brauchen WebAssembly, um eben den nativen existierenden Code in den Browser zu bekommen. Wir brauchen alternative Sprachen, um vielleicht mehr Leute in die Community zu bringen, um das Web noch breiter aufstellen zu können. Das richtig große Big Bang Disruptive Thing gibt es glaube ich nicht mehr. Es wird eine Mischung von vielen Dingen sein.
Julia Martin: Vielen Dank, dass du heute bei uns warst.
